Subject: Ambiguities in QoS path management

From: Paul Ferguson <[email-masked]>
Date: Mon, 04 Aug 1997 22:09:01 -0400

Bear with me on this, it may just be that I haven't properly parsed
the implications of the referenced drafts. It appears that there is
either (a) a bit of ambiguity in the statement that RSVP is not
responsible for the pinning of paths, or (b) I've completely
misinterpreted the context of these remarks.

A clarification would be appreciated, or perhaps better articulated
in draft-guerin-ext-rsvp-routing-intf-00.txt.

In [draft-guerin-ext-rsvp-routing-intf-00.txt]
[Section 2.2, QoS Routing Support] states:

[snip]

   Path management can be performed by either RSVP or routing.  However,
   in order to avoid burdening RSVP with functions that fall outside of
   the scope of a resource reservation setup protocol, path management
   should be the responsibility of QoS routing and not of RSVP. This is
   consistent with the use of the notify flag defined in the current
   interface between RSVP and routing, where routing is responsible
   for detecting the failure of the path of an existing flow and
   asynchronously notifying RSVP of this event.  In the case of QoS path
   management, additional failure conditions need to be considered,
   e.g., reservation failures, so that a single flag is not sufficient
   to support this function.  This is best illustrated by an example
   that will motivate the need for extended notification capabilities
   between RSVP and routing.

[snip]

However, if I've parsed this (and other related drafts) correctly,
RSVP is indeed responsible for pinning paths, in that:

[draft-guerin-qospath-mgmt-rsvp-00.txt]
[Section 1. Introduction]

   (i) What is pinned is a ``path'' taken by a specific RSVP flow and
       not a ``route'' as computed by the routing algorithm.  Hence
       pinning and unpinning are RSVP domain operations, and as a result
       completely independent of the specific QoS routing algorithm
       being used.

  (ii) Path pinning and unpinning is kept ``soft'' by tying it to the
       existing RSVP soft state mechanism.  In other words, we rely on
       existing RSVP refreshes and time-out mechanisms to detect the
       state changes that trigger pinning and unpinning of paths.  In
       addition, such changes are triggered only on the basis of current
       RSVP state information.

[snip]
[Section 2. Path Management (Pinning and Unpinning) State and Rules]

    1. Paths get pinned during processing of PATH messages.

    2. Paths get unpinned when

       (a) corresponding path states are removed (time-out or
           PATH_TEAR),

       (b) some of the parameters received in PATH messages change,

       (c) a local admission control failure error is detected after
           receiving a RESV message,

       (d) a PATH_ERR with a specific error code is received, or

       (e) failure notification of a local link belonging to the path is
           received.

[snip]

- paul

---

From: Tony Li <[email-masked]>
Date: 05 Aug 1997 00:59:05 -0700

Paul,

My understanding is simple:

- routing computes the path
- RSVP instantiates it

Note that I've not used the word "pinning" cause I'm not quite sure that we
have a common understanding of what that would mean.

I would expect RSVP to do the signaling function to establish and maintain
the path as computed by routing.  I would expect RSVP to discover (via
normal path failure mechanisms) if there is an infrastructure failure and
notify routing.  Similarly, I would expect routing to discover that
particular paths are no longer appropriate and notify RSVP that certain
paths need revision.

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 5 Aug 97 17:44:59 JST

> misinterpreted the context of these remarks.

The fundamental confusion is that people confuse routing and
a routing protocol.

Routing is a path determination mechanism. Routing is performed
on routers.

A routing protocol is a way to globally distribute generic routing
information. A routing protocol is exchanged between routers.

RSVP is not a routing protocol.

RSVP is a transport to distribute flow-specific information on
routers along the path of the flow.

Routing may make use of routing information not distributed by
routing protocols.

RSVP does interact with routing.

RSVP is the scalable transport to distribute flow-specific routing
information on routers along the path of the flow.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 5 Aug 97 17:44:59 JST

Masataka Ohta

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 05 Aug 1997 05:50:03 -0400

Okay, now that you've reiterated points that I am already
aware of, perhaps someone can offer something more
substantive?

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 05 Aug 1997 05:50:03 -0400

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 05 Aug 1997 06:13:01 -0400

>- routing computes the path

This is my understanding as well. Thanks for the sanity check.  :-)

All in all, it is the interaction of routing and RSVP message processing
mechanics which determine when paths are 'pinned' and 'unpinned'. To say
that one or the other is responsible (or not) is not quite correct. That
was my original point.

Thanks,

- paul

---

From: "Thomas P. Koltai" <[email-masked]>
Date: Tue, 5 Aug 1997 22:46:04 +1000 (EST)

On 5 Aug 1997, Tony Li wrote:

> paths need revision

Our thinking on this is that, a routing arbiter still needs to be computer
based with the results updating routing tables. Our concerns are the i/o
time on current "acceptanble" computer OS's. 

RSVP therefore appears to need a "next best guess" table based on a memory 
table model. With only 12% DNS currently active that is still 8 Gb which
is awkward in a router only model.

Tom

---

From: Daniel Zappala <[email-masked]>
Date: Tue, 05 Aug 97 11:36:58 PST

Paul,

I'll try to clear up some of the confusion surrounding the drafts
issued by Guerin et al.  Hopefully they don't mind too much.

The first one you reference:

[1]	[draft-guerin-ext-rsvp-routing-intf-00.txt]

is a proposed extension to the RSVP-routing interface.  The primary
additions here are mechanisms for RSVP to carry opaque routing objects,
specifically a source route object and/or an MPLS object.  RSVP doesn't
know the contents of these objects, but passes them to routing at each
hop for interpretation.  RSVP also determines how it will route Path messages
using these objects.

This portion of the above draft follows their guidelines, which you cite,
for having routing do the pinning and not RSVP.  A specific example of
this is the draft:

[2]	[draft-guerin-expl-path-rsvp-00.txt]

Now, the interface draft ALSO includes mechanisms for RSVP to take a bit
more active role in pinning routes by passing along PHOP and ttl information.
The specific example the authors have in mind is their previous draft
on doing pinning of hop-by-hop QoS routes, given in:

[3]	[draft-guerin-qospath-mgmt-rsvp-00.txt]

You appear to have combined draft [3] with [1] when really [2] is the
primary companion to [1].

Your confusion is understandable, however, because [1] really does contain
language supporting both [2] and [3].  From what I can read into these
documents, the authors would prefer to use an explicit-routing based route
pinning approach, in which routing does the pinning and not RSVP [2].
However, they are basically throwing everything into the RSVP-routing
interface so that if someone wanted to have RSVP help out with pinning,
as with [3], then they could do that too.

All of this is for unicast sessions only.  I have some ideas on how to
do multicast route pinning that I have presented to the working
group before.  I have a paper on that available at my home page if
you are interested, and at some point I'll add the slides from my
QoSR talk in Memphis (they are at the ietf.org site I believe).

Daniel Zappala
[email-masked]
http://netweb.usc.edu/daniel

---

From: Roch Guerin <[email-masked]>
Date: Tue, 05 Aug 97 15:00:04 -0400

Paul,

A few a words of clarifications regarding the drafts and the issue of
path management.

First as you correctly pointed out in your response to Tony's note,
 
>that one or the other is responsible (or not) is not quite correct. That

This being said, there is some flexibility as far as function
placement is concerned, i.e., where is the relevant (path) information
kept and which component is responsible for identifying events that
are capable of triggering changes to an existing path, e.g., pinning
and unpinning.  In particular, one can place some of these
responsibilities with either RSVP or routing.  It does not change the
fact that path management is based on interactions between routing and
RSVP message processing, but does affect when an how these
interactions are initiated.  

At one extreme, you can choose to have RSVP be entirely
oblivious to any aspect related to path management and rely entirely
on routing to make the appropriate decisions.  This requires that RSVP
make available to routing all the necessary information for routing to
detect any relevant change in RSVP state, etc.  Alternatively, it is
possible to offload some of this responsibility to RSVP by making it
aware of which (RSVP) events are relevant to path management, e.g.,
changes in PHOP or hop count.  The trade-off here is between
duplicating some of the RSVP state information to allow routing to
detect and act on relevant RSVP state changes, and requiring RSVP to
perform these additional checks to know when it needs to interact with
routing.  In both cases, interactions are based on the same
information, the difference is in who keeps and reacts to that
information. 

In the draft [draft-guerin-qospath-mgmt-rsvp-00.txt] we actually
described an approach where the responsibility of path management was
split between RSVP and routing.  The motivation for this choice was
that because of the hop-by-hop nature of the path "setup", quite a bit
of the path management had to do with loop detection, which involved
some simple checks on existing RSVP state changes.  Rather than
replicating all the associated state information and processing in
routing, we took the option of making RSVP responsible for some of
it, i.e., detect relevant state changes to determine when it needed to
interact with routing for the purpose of path management.

In the draft [draft-guerin-expl-path-rsvp-00.txt] we actually chose a
different approach, where routing was now responsible for essentially
all of the path management functions.  This was motivated by the fact
that in the context of the explicit routes assumed in that draft,
there is less reliance on existing RSVP states.  In particular, most
of the relevant information is contained in the "opaque" route object,
which RSVP is not (should not be) required to parse (this is routing's
job).  As a result, we took the position that in the case of explicit
routes, RSVP should not be actively involved in path management.
Instead, RSVP's role should be limited to making all the relevant
information available to routing which will then use it to take
appropriate path management decisions.

I agree that this may have been a source of confusion as it specifies a
different approach from that of [draft-guerin-qospath-mgmt-rsvp-00.txt].
However, note that the possibility of such a different function placement
is already mentioned at the end of this previous draft (see Section
4).  In general, one could actually view the choice of function
placement as an implementation issue, that only affects the internal
(to the router) interactions between RSVP and routing.  Right now, we
have actually converged on a design (for both hop-by-hop and explicit
routes) where the path management responsibility is essentially with
routing, i.e., indeed different from the approach initially described
in [draft-guerin-qospath-mgmt-rsvp-00.txt].  This was motivated by the
need to not only minimize changes to RSVP, but also and probably more
important because we ultimately felt it was the better function
placement.  In particular, the amount of (RSVP) state information that
routing then has to maintain, turns out to be little more than what is
already needed to support functions such as route (path) change
notification.  We'll update the draft 
[draft-guerin-qospath-mgmt-rsvp-00.txt] to explicitly reflect this
function placement.

Finally, in the draft [draft-guerin-ext-rsvp-routing-00.txt], we have
tried to define an interface between routing and RSVP that not only
allows support of different routing mechanisms, but also easily allows
off-loading of the associated path management to routing.  

Hope this helps "clarify" things.

Roch

---

From: Daniel Zappala <[email-masked]>
Date: Tue, 05 Aug 97 11:45:57 PST

> - routing computes the path

Tony,

I would clarify the source route approach in

	[draft-guerin-ext-rsvp-routing-intf-00.txt]
and
	[draft-guerin-expl-path-rsvp-00.txt]

as:

- routing computes the route
- RSVP carries the route as an opaque object in a PATH message
- at each hop, RSVP gives the route object to routing for interpretation,
  receiving in turn an updated route object and instructions on where
  to forward the PATH message
- routing determines when the route is no longer functional and notifies
  RSVP as appropriate

> have a common understanding of what that would mean.

In this case the route is 'pinned' in the sense that it will remain in
place unless it fails.  This is of course straightforward with a source
route.

Note that routing is the entity that will determine whether the next
hop in the source route is alive.  This is easier if the route is a strict
route.  If it is loose, then I'm not sure what the authors think routing
should do.

RSVP uses refreshes of Path messages carrying the route to maintain its
cache of forwarding state.  So if there is a failure, the downstream
state will timeout, but routing will need to notify RSVP so that it
stops carrying the route --- RSVP has no other mechanism to detect
the failure.  RSVP can either get a new route or just use adaptive
routing at that point.

> particular paths are no longer appropriate and notify RSVP that certain

I apologize if I have put too many words in the authors' mouths.

Daniel Zappala
[email-masked]

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 05 Aug 1997 16:27:18 -0400

>issued by Guerin et al.  Hopefully they don't mind too much.

Daniel,

Thanks -- this helped tremendously.

- paul

---

From: Tony Li <[email-masked]>
Date: 05 Aug 1997 13:55:45 -0700

> route.  If it is loose, then I'm not sure what the authors think routing

Using the routing protocols, routing should compute a path (usually the
shortest path according to whatever metrics are in use ;-) to the next item
in the source route.  That path would imply another next hop.  At least I
would assume that this is the intent as this is what happens for IPv4 loose
source routing.

> > particular paths are no longer appropriate and notify RSVP that certain

We must be arguing semantics because I think we're in total agreement, with
one minor difference (what happens on a failed refesh).

Tony

---

From: Roch Guerin <[email-masked]>
Date: Tue, 05 Aug 97 18:43:29 -0400

Daniel,
Your note is a very good summary of the issues and I wish i had seen
it before sending out my earlier response.  would have saved me time ;-)

Roch

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Aug 97 13:32:49 JST

> aware of, perhaps someone can offer something more

OK. Fine.

Let's be a little more substantive.

As QOSPF scheme use a routing protocol to globally distribute flow
specific routing information, QOSPF is not scalable and is no good.

As PATH messages can carry all the flow-specific QoS link state
information to prevent route flipping, there is no need to use
route-pinning.

Have you already aware of the above two almost direct conclusions?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Aug 97 13:32:49 JST

OK. Fine.

						Masataka Ohta